23. Projekt zespołowy - tydzień 1 z 3

Ten moduł rozpoczyna Twoją pracę w projekcie zespołowym. Dzięki temu wyzwaniu zobaczysz, jak może wyglądać Twoja pierwsza praca na stanowisku Junior Web Developera, oraz jak wygląda organizacja pracy wielu osób.

W czasie projektu zespołowego nie będziemy Cię zaznajamiać z nowymi zagadnieniami typowo technicznymi, lecz postawimy na rozwinięcie Twojej świadomości na temat pracy grupowej.

Jak wspomnieliśmy, ten projekt ma być dla Ciebie treningiem sytuacji, z jaką spotkasz się w pracy. W takim razie zaczynamy od poznania historii naszego projektu...

Historia projektu

Wyobraź sobie, że mija kilka dni od Twojej rozmowy rekrutacyjnej. Tracisz już nadzieję, kiedy nagle w piątek dzwoni telefon — gratulacje! Masz pracę! Jesteś Junior Web Developerem na etacie! Świętujesz w piątek, może nawet w sobotę też, ale niedziela już jest czasem na odpoczynek i zebranie sił.

Przychodzi poniedziałkowy poranek, przychodzisz do pracy, dowiadujesz się, że dołączysz do zespołu Web Developerów. Poznajesz ludzi, podstawowe procedury obowiązujące w firmie oraz całą firmową kulturę. Wreszcie nadchodzi czas na rozpoczęcie właściwej pracy.

Jesteś Juniorem, więc nie dostajesz zupełnie świeżego projektu — łatwiej będzie Cię wdrożyć w już rozpoczęty projekt. Rozpoczął go inny developer, który musiał zostać przełączony do większego i pilnego projektu. Dzięki temu wiesz, że projekt jest całkiem nieźle zaczęty, ale wymaga sporo pracy, zanim będzie ukończony.

Całe szczęście, razem z Tobą przyjęto też innych Juniorów. W kilka osób macie w ciągu 3 tygodni dokończyć projekt. Wymagana jest tylko strona główna, ale już pierwszego dnia przy kawie ustalacie, że dobrze by było zrobić świetne wrażenie i wykonać jeszcze więcej! Czy się uda? Zobaczymy...

Projekt będzie prowadzony przez doświadczonego Project Managera (PMa), a do tego developerzy z większym stażem będą codziennie zaglądać do Waszego kodu i odpowiadać na Wasze pytania. Pamiętaj jednak, że PM ma wiele projektów pod opieką, a doświadczeni developerzy — swoje własne zadania. Nie będą dostępni przez cały czas, więc warto, żebyście w Waszym zespole projektowym rozmawiali ze sobą i pomagali sobie nawzajem.

Co więcej, żeby szybciej się uczyć, już niedługo zaczniecie też sobie nawzajem sprawdzać kod — ale nie wszystko od razu.

Tyle tytułem historii projektu i wczucia się w sytuację. Przechodzimy do konkretów!

Skład zespołu

Twój zespół projektowy składa się z:

• Kursantów, którzy będą realizować projekt,
• Project Managera (PM-a), którego rolę będzie pełnił jeden wybrany przez nas Mentor. W czasie prac będzie on m.in.:
  • sprawdzać Wasz kod, zanim zostanie merge'owany do głównego brancha (mastera),
  • pomagać Wam dobrze zrozumieć zadania do wykonania,
  • odpowiadać na Wasze pytania na komunikatorze.

Narzędzia wykorzystywane w czasie projektu

Za chwilę szerzej omówimy, jak będziecie wykorzystywać narzędzia, ale zaczniemy od ich wymienienia:

• treść modułów – w tym i kolejnych 3 modułach znajdziecie istotne informacje, które pomogą Wam w realizacji projektu,
• komunikator – specjalny kanał zespołu pozwoli Wam na pozostawanie w kontakcie i rozmowy na temat projektu, a także kontakt z PM-em i Mentorami,
• Jira – jest to bardzo popularny system zarządzania projektami, z którym zapewne nie raz spotkasz się w swojej karierze, w nim są rozpisane zadania,
• GitHub – znany już Wam dobrze GitHub pozwoli na zastosowanie w praktyce wiedzy dotyczącej branchy i merge'ów.

Największą nowością spośród narzędzi jest niewątpliwie Jira. Jeśli dotąd nie zdarzyło Ci się spotkać z żadnym systemem zarządzania projektami, możesz wyobrazić sobie Jirę jako rozbudowane Trello, czyli Kanban board. Jest bardziej skomplikowana, ale ma też o wiele większe możliwości. W naszym projekcie użyjemy tylko jej podstawowych funkcjonalności, ale warto już na tym etapie zaznajomić się z Jirą, ponieważ używa jej wiele software house'ów, a inne systemy zarządzania projektami działają często na podobnej zasadzie.

Praca w zespole często bywa nie lada wyzwaniem. Z tego powodu każdy zespół musi mieć ustalone zasady, wedle których współpracuje. Dla większości z Was to pierwszy zespołowy projekt developerski więc przygotowaliśmy dla Was zestaw wytycznych. Dzięki temu praca powinna Wam pójść znacznie sprawniej.

Komunikacja w zespole

Nie da się przecenić roli dobrej komunikacji w czasie wspólnej pracy. Ważne jednak, żeby to była dobra komunikacja — wcale nie musi jej być dużo. Dlatego w ramach projektu będziecie się uczyć, jak najlepiej porozumiewać się ze sobą i koordynować prace.

1. Spotkania zespołowe:

• raz w tygodniu odbędzie się video rozmowa całego zespołu, na której będziecie mieli okazję wymienić się doświadczeniami i porozmawiać o ewentualnych problemach,
• spotkanie trwa 45 minut,
• ważnym elementem spotkań jest retrospekcja, czyli zastanowienie się, co pomogło, a co przeszkadzało w realizacji zadań — początkowo może się to wydawać szukaniem winy, ale jest to kluczowy element spotkań, który pozwala na wyciąganie wniosków i usprawnianie dalszej pracy,
• jeśli w gronie Kursantów chcecie dalej rozmawiać, to możecie, ale pamiętajcie, żeby nie przesadzić — często lepiej spędzić czas z kodem niż na nadmiarowych rozmowach, nawet jeśli są fajne.

2. Daily, czyli codzienne podsumowanie pracy developera:

• codziennie na koniec pracy każdy Kursant wysyła na kanale zespołu podsumowanie swojej pracy danego dnia oraz plany na kolejny dzień,
• dzięki temu wszyscy członkowie zespołu wiedzą co robią inni,
• to jest też okazja do zgłoszenia "dni wolnych", czyli takich, w których dana osoba nie będzie pracować nad projektem (ani wysyłać daily),
• to nie ma być wypracowanie, tylko krótkie podsumowanie! Przykład znajdziesz w następnym rozdziale.

3. Jira, czyli system zarządzania projektem:

• każde zadanie jest do kogoś przypisane (tzw. assignee) i ma swój status (np. "in progress"), dzięki czemu wszyscy wiedzą, które zadania są właśnie robione, a co pozostaje do zrobienia,
• w przypadku problemów lub wątpliwości dotyczących konkretnego zadania najlepiej opisać je w komentarzu do danego taska i wtedy poprosić o pomoc (z linkiem do taska) na kanale zespołu.

4. Repozytorium

• choć dziwi to początkujących developerów, repozytorium jest również formą komunikacji,
• trzymanie porządku w repozytorium pozwoli uniknąć wielu problemów i usprawni komunikację z innymi członkami zespołu, w tym z Mentorami sprawdzającymi Wasz kod,
• w jednym z poniższych rozdziałów wymieniliśmy kilka prostych zasad — trzymaj się ich!

5. Bieżące rozmowy na komunikatorze

• pamiętaj, że wszyscy są zajęci i nikt nie lubi być co chwilę odrywany od pracy — dlatego najlepiej zebrać kilka pytań i zadać je naraz, koniecznie ponumerowane,
• staraj się nie zaśmiecać kanału — jeśli to możliwe, przechodź na priv lub do komentarzy w Jirze.

Jak napisać daily

Choć z początku napisanie daily może wydawać się banalne, napisanie go tak, aby przekaz był jasny, jest nie lada sztuką. Nie rozpisuj się za bardzo, to ma być krótkie podsumowanie. Pilnuj formatu nagłówka, kolejne informacje pisz w punktach, wytłuść to, na co inni mają koniecznie zwrócić uwagę (np. prośbę o pomoc).

Spójrz na ten przykład daily:

*DAILY 25.01.2020*
- naprawiłem buga XXX i zacząłem zajmować się taskiem YYY.
- z tym ostatnim mam problem i *potrzebuję pomocy* (szczegóły za chwilę).
- jutro będę dalej pracować nad YYY, myślę że uda się skończyć, więc przydzieliłem też do siebie ZZZ.

Szczegóły dot. problemu z YYY są w komentarzach:
https://projects.kodilla.com/

• nagłówek jest pogrubiony za pomocą znaków *,
• kolejne punkty zaczynaj od -,
• w miejscu XXX, YYY i ZZZ powinny być numery tasków/bugów, żeby nie było wątpliwości, czym się zajmujesz,
• jeśli prosisz o pomoc, podaj linka, żeby inni nie musieli go szukać,
• powtórzymy jeszcze raz — nie rozpisuj się, pozwól innym szybko zapoznać się z Twoim daily, i wejść w szczegóły, tylko jeśli mogą poświęcić na to czas.

Te wskazówki sprawią, że Wasza komunikacja będzie znacznie wydajniejsza. Nie będziecie przekrzykiwać się na kanale ani przegapiać newralgicznych informacji.

Przydzielanie zadań

Każde z Was samodzielnie przypisuje do siebie zadania w Jirze, przy czym:

• nie przypisuj do siebie zadania, jeśli masz już przypisane dwa zadania o statusie queued lub in progress. Kolejne możesz przypisać do siebie, dopiero kiedy skończysz bieżące i wyślesz je do sprawdzenia (in review),
• pamiętaj, że zadanie może zostać skierowane do poprawy w trakcie sprawdzenia, wtedy wróci do statusu queued,
• zwracaj uwagę na kolejność zadań w backlogu. PM ustala kolejność zadań do realizacji, więc wybierz jedno z 3-5 z samej góry.

Te zasady nabiorą więcej sensu po przeczytaniu rozdziału o Jirze, kiedy poznasz workflow zadania, czyli w jaki sposób mogą się zmieniać jego statusy.

Praca w repozytorium

Jak już wspomnieliśmy, repozytorium jest też formą komunikacji i wymaga trzymania porządku. Na potrzeby naszego projektu ustalamy, że:

• jeśli pracujesz nad bugiem o numerze 1234 (numery tasków i bugów znajdziesz je w Jirze, za chwilę opiszemy gdzie dokładnie), nazwij branch np. bug-1234,
• pilnujemy nazewnictwa commitów zgodnie z dobrymi praktykami opisanymi w module o Narzędziach Developerskich (np. "Add footer responsive styles"), dzięki temu nikt nie będzie musiał Cię pytać, co było zmienione w danym commicie, albo w którym commicie znaleźć zmiany stylów danego elementu.

W repozytorium nie będziesz mieć możliwości wysyłania commitów na branch master. To jest bardzo częsta praktyka, która pozwala zapewnić dobrą jakość kodu w głównym branchu. Zamiast tego, po wykonaniu zadania wykonujesz Pull Request, który jest zgłoszeniem prośby o merge'owanie Twojego brancha do mastera (za chwilę wyjaśnimy jak to zrobić).

Uwagi do pull requestów

1. Zakładając pull request, w tytule należy podać numer zadania z Jiry (w tym samym formacie, co nazwa brancha).
2. Jako opis podaj następujące informacje: opis problemu (co się dzieje, a co powinno się dziać) oraz opis działania rozwiązania.
3. Pamiętaj o oznaczeniu reviewerów.
4. Jeśli pracujesz jeszcze nad zadaniem, ustaw mu label WIP, który jest skrótem od "Work In Progress".

Punkt 4. nie powinien się zdarzać zbyt często, ale może się zdarzyć, że po wykonaniu pull requesta przypomnisz sobie, że jeszcze coś zostało do zrobienia, albo wpadniesz na pomysł lepszego rozwiązania.

Witaj w Jirze! Oto nasza tablica Kanban. Będzie ona dla Ciebie jednym z podstawowych narzędzi w naszym systemie zarządzania projektami, więc poświęćmy chwilę, by się z nią zapoznać.

Tablica Kanban

Nasza tablica składa się z 6 kolumn. Każda odpowiada jednemu ze statusów, jaki może przyjąć w naszym systemie pojedyncze zadanie (task). Patrząc od lewej, kolumny noszą nazwy:

• Backlog – taski oczekujące na przejęcie przez developera,
• Queued – taski przypisane do developerów, oczekujące na rozpoczęcie prac nad nimi (prace jeszcze nie ruszyły),
• In Progress – taski, którymi zajmuje się w danej chwili developer,
• In Review – taski, znajdują się w code review, czyli czekają na sprawdzenie,
• Done – taski zakończone i zaakceptowane przez Mentora.

Jeśli w czasie review okaże się, że task wymaga poprawy, wróci on do kolumny Queued.

Taski możesz przenosić z jednej kolumny do drugiej, łapiąc je myszą i przeciągając w odpowiednie miejsce:

Musisz wiedzieć, że przesunięcie zadania z jednej kolumny do drugiej może zmienić nie tylko status, ale mieć też inne konsekwencje. W przypadku naszej konfiguracji:

• przeniesienie zadania z Backlog do Queued spowoduje przypisanie zadania do Ciebie,
• przeniesienie zadania z In Progress do In Review spowoduje przypisanie zadania do PM-a.

Wynika to z tego, że zadanie powinno być zawsze przypisane (assigned) do osoby, która ma się nim zajmować.

Statusy możesz zmieniać również za pomocą guzików, w pełnym widoku taska, który omówimy za chwilę.

Filtrowanie zadań na tablicy

Bardzo przydatną opcją tablicy Kanban, zwłaszcza gdy wypełnia się ona taskami wykonywanymi przez kilku developerów z Twojego zespołu, jest możliwość wyfiltrowania tylko tasków przypisanych do Ciebie. Aby zobaczyć na tablicy tylko swoje taski, kliknij "Only My Issues":

Widok zadania

Mamy tablicę naszego projektu — fantastycznie! Czas zapoznać się ze znajdującymi się na niej taskami. Jak widzisz, jest ich już kilkanaście. Aby otworzyć task, kliknij po prostu jego numer.

Uwaga: kliknięcie lewym przyciskiem myszy otworzy zadanie w prawej części okna, w którym się znajdujesz. Możesz też otworzyć zadanie w nowej karcie — taki właśnie ekran prezentuje poniższy zrzut.

Widok taska zawiera bardzo wiele informacji — dla nas na tę chwilę najważniejsze będą elementy zaznaczone numerami:

1. Numer taska – służy identyfikacji danego zadania. Dla każdego zadania będziesz tworzyć nowy branch na GitHubie, o takiej samej nazwie, jak numer zadania (np. branch o nazwie WT01-11).
2. Tytuł taska – krótko opisuje, co zawiera dany task.
3. Guziki akcji – umożliwiają zmianę wielu parametrów taska:
   • Edit – rozbudowany ekran edycji taska
   • Comment – rozwija pole na komentarz
   • Assign – przypisane taska do innej osoby
   • More – zestaw bardziej zaawansowanych opcji; raczej nie będziesz ich potrzebować w tym projekcie
   • Add to queue – dodanie taska do kolejki zadań do wykonania (po zmianie statusu z Backlog na inny, będą pojawiać się inne guziki zamiast Add to queue)
4. Typ taska – możliwe wartości tego pola to "Bug" i "Task". Bugi to zadania, gdzie Twoją rolą będzie poprawienie błędu w działaniu strony, natomiast Taski to nowe funkcjonalności lub widoki, które należy zaimplementować.
5. Status – wskazuje, w której kolumnie na tablicy Kanbana znajduje się dany task. Obok zobaczysz bardzo interesujący link — View Workflow. Za chwilę opiszemy czym jest Workflow i dlaczego jest dla nas ważny.
6. Assignee – osoba, do której przypisany jest dany task (czyli ta, która aktualnie się nim zajmuje).
7. Opis taska – bardziej szczegółowe instrukcje, czego dotyczy konkretne zadanie.
8. Pliki – załączniki do taska. Mogą to być np. screenshoty lub pliki .psd.
9. Komentarze – dyskusje dotyczące danego zadania.

Workflow

W Jirze mamy skonfigurowany konkretny algorytm zmian statusów zadania, który jest przedstawiony na tej ilustracji:

Oznacza to, że nie można np. zmienić statusu zadania z Backlog na Done. Można podążać tylko wyznaczonymi ścieżkami, nazywanymi często ścieżką życia zadania. Co więcej, tylko Mentorzy mogą zatwierdzić zadanie, czyli zmienić mu status na Done.

Jest to bardzo prosty Workflow, w porównaniu z tym jakie stosuje się w zespołach developerskich. Pozwoli on nam jednak na przyzwyczajenie się do tego, że statusy zmieniamy wedle określonej ścieżki życia zadania.

Nauka przez praktykę

Żeby lepiej zapoznać się z Jirą, możesz stworzyć własnego taska za pomocą guzika Create na samej górze strony. Koniecznie zacznij nazwę od "TEST" - wtedy PM będzie wiedział, że to jest task stworzony do zapoznania się z Jirą.

Etapy prac

1. Naprawa nagłówka strony głównej
2. Stworzenie podstawowych komponentów
3. Dodanie brakujących sekcji
4. Stworzenie widoku produktu
5. Stworzenie widoku listy produktów w obu wariantach

Zadania

Zadania z etapów 1-3 są opisane w Jirze. Etapy 4-5 będziecie musieli samodzielnie rozpisać na zadania.

Pliki

• Home.psd - projekt strony głównej
• Shop.psd - projekt widoku produktów
• Products_Grid.psd - projekt listy produktowej w wariancie grid
• Products_List.psd - projekt listy produktowej w wariancie listy

Wymagania

• nie używamy jQuery
• strona ma estetycznie wyglądać w rozdzielczościach 320px - 1920px
• Klient nie może dostać rozsypanej strony — jeśli nie uda się dokończyć jakichś zadań, to nie wrzucamy ich na master

Zaliczenie projektu

• wykonanie przez developera zadań za co najmniej 15 Project Points (są przy każdym zadaniu w Jirze)
• zrealizowanie minimum 3 z 5 aktywności dodatkowych (regularne daily, minimum 4 code review, obecność na spotkaniach wideo, aktywny udział na czacie, dostarczenie projektu)
• zrealizowanie wszystkich zadań z etapów 1-2 (kolejne etapy są opcjonalne)

Dodatkowo zalecamy osobisty deployment projektu na Netlify lub Heroku, aby każdy z uczestników projektu mógł zobaczyć działający, ukończony projekt.

1. Przeczytaj dokładnie ten moduł.
2. Przejrzyj jeszcze raz ten moduł, a w szczególności zasady pracy w projekcie.
3. Sprawdź, czy masz dostęp do Jiry oraz kanału projektu (prefix project-) - jeśli nie, daj nam znać na support@kodilla.com.
4. Wejdź na kanał projektu, przywitaj się z pozostałymi członkami zespołu. Jeśli na mailu nie masz jeszcze zaproszenia do repozytorium projektu, poproś PM-a o dodanie do repozytorium.
5. Sklonuj repozytorium.
6. Wejdź do Jiry i wybierz sobie pierwsze zadanie. Przypisz je do siebie przenosząc je do kolumny Queued.
7. W repo stwórz odpowiedni branch, którego nazwa będzie odpowiadać zadaniu z Jiry (np. task-1234).
8. Jeśli możesz od razu zacząć pracę nad tym zadaniem, przenieś je w Jirze do kolumny In Progress.
9. Zrealizuj zadanie.
10. Po zakończeniu zadania wypchnij zmiany do zdalnego repozytorium (bez merge'owania do mastera).
11. Wejdź na (GitHuba)[https://github.com] i zrób Pull Request.
12. W Jirze przenieś zadanie do kolumny In Review, a w komentarzu do tego zadania podaj linka do Pull Requesta.
13. Wróć do punktu 6, jeśli zostały jeszcze jakieś zadania.
14. Jeśli nie ma już zdefiniowanych zadań, wróć do specyfikacji projektu (powyżej) i stwórz nowe zadania.